1. The Field of the Invention
The present invention relates to electronic networked mapping services; and more specifically, to comprehensive mapping data structures and methods for using the same.
2. Background and Related Art
Computing technology has transformed the way we work and play. Computing systems may now perform a variety of functions including the accessing of services provided over a network or the Internet. One important class of services offered over a network relate to mapping services. For instance, a user may specify a location, and obtain a map centered at that location. The user may navigate to the left, right, up or down to change the center point of the map, and may zoom in or out on the map to thereby change the level of map detail. A user may also specify two locations, and have the mapping service estimate the fastest or shortest route between those two locations. The route may be conveniently highlighted on the rendered map. Accordingly, mapping services provide a useful resource that allows individuals to view maps and navigate from one location to another.
The mapping service typically provides a user interface that is relatively straightforward and user-friendly. However, hidden from the user are the many detailed and complicated functions that support such a user-friendly environment. In fact, those designing and drafting code for such mapping applications are faced with many challenges.
For instance, there are many ways that a user may wish to describe a location. For example, a user may specify an exact position by longitude, latitude and potentially also altitude. A user may also specify a location by its postal address or by its name. For example, a user may specify a location as 34 West Eighth Street, FictionTown, FictionState, or may specify a location such as “FictionTown Court House”. To allow for mapping using any of these ways of specifying a location would require significant coding efforts. Accordingly, to avoid such extensive coding efforts, many mapping services do not allow for the identification of the location using all of these various ways of specifying a location. Instead, the user is simply required to conform to a fewer number of specific ways of designating the location. Alternatively, different data structures are used to describe locations using different descriptive ways, thereby making it quite complex in terms of lines of code to interface with all of those different location data structures.
Another difficulty is associated with how a best view for the map is identified. When a location is rendered, the location is typically rendered in the appropriate center of the map. However, depending on the location, different map views having different zoom factors may be appropriate. For example, if the location is the “United States”, the map view would be centered at around the center of the United States (e.g., possible somewhere in Kansas). However, the zoom factor would be relatively low thereby allowing all of the United States to be rendered in a single window. On the other hand, if the location were “Kansas”, the center of the map would be somewhere in the appropriate middle of Kansas with the zoom factor being somewhat greater including all of Kansas, but not all of the United States.
The map view may be specified in a number of different ways. For example, the map view may be properly represented by the center point, the height, and the width of the map; by the center point and scale of the map; by the location of two opposite corners of the map; or the like. Mapping services typically define a map view using only one of these ways, or else use a different data structure for defining a map view in different ways. The programmer that programs an application that uses the mapping service chooses which map view representation is most appropriate for the application being programmed. For example, if the application is to determine whether a particular location is within a map view, the programmer may choose a map view that is expressed in terms of two opposite corner points since it is easiest to make that determination with a map view expressed in such a way. On the other hand, it would be much harder for the programmer to design code to make that determination if the map view is represented in terms of center point and scale.
However, in order to program to a specific map view representation, the programmer needs to understand the basic structure and interfaces associated with that map view representation. If the programmer were to interface with a different map view representation, the programmer may need to learn entirely different basic structures and interfaces associated with that different map view. This poses quite a burden on the programmer of mapping applications.
For example, if a map view is to be zoomed in on by a factor of two, then the map view is more easily changed using fewer processor cycles if the map view is represented using the center point and a scale, as compared to representing the map view using a location of two opposite corners. On the other hand, if the map view is simply to be shifted left, right, up or down, the processing may be less intensive if the map view is represented using the location of two opposite corners, as compared to representing the map view using a center point and scale.
Furthermore, a different route data structure is conventionally used to describe route information depending on the progress of route calculation. For instance, a route calculation request may include two end-points. The route calculation service may respond with a different data structure that includes that calculated route between the two end-points. A render request may be a different data structure altogether and may include the two-end points or perhaps the calculated route. To interact with each of these data structures, a programmer would need to understand these several data structures.
In addition, when calculating a route, it is not always clear to the client application that interfaces with the user whether or not the fastest route or shortest route was used to calculate the route, particularly if the client application did not itself specify which option is to be used when the client application initially requested the route calculation. There are cases in which it would be helpful for the client application to know how the route was calculated.
For example, the client application may display that the route was calculated using the fastest route. That may help the user realize how the route was calculated. Furthermore, sometimes when calculating a route, the two end-points may be “snapped” to a near location that may be used to more easily calculate a route. For example, “road snapping” replaces the designated end-points with the nearest road intersection. “City snapping” or “highway snapping” replaces the designated end-points with the nearest highway.
Such snapping may more closely conform with the intent of the user. For example, if the user specifies “Topeka, Kans.” as one location, the location associated with Topeka, Kans. may actually be represented by a specific central location as identified by longitudinal and latitudinal coordinates. However, the user may not be interested in traveling to or from that specific central point, but perhaps only from the main highway leading through Topeka. However, the mapping service typically does not specify how the end-points were snapped. Accordingly, the client application may not take appropriate action in response to such knowledge.
Accordingly, what would be advantageous is a mapping service in which locations and map views may be represented in different ways without increasing the complexity associated programming using the locations and map views. What would further be advantageous is if route calculation could be performed using more standardized data structures to improve ease of programming. Furthermore, what would be advantageous is a mapping service in which the requesting application was properly notified of the options used to calculate the route.